Day 7 : Backstage 內部員工身份認證：從 AD 同步到 SSO 的實施之路

16th鐵人賽 backstage spotify cncf

jincoco88912

2024-09-16 05:20:46

122 瀏覽

分享至

前言

以公司遇到的情境為例，隨著公司發展了一段歷史，並且旗下擁有的品牌與服務也越來越多，可惜的是在每個服務幾乎都是獨立擁有自己的系統，也就是說即便都掛在同個集團名下，但實際使用時卻需要重複註冊測一次。用戶可能會覺得說：「奇怪，記得這家也是你們公司的，為什麼我還要重新輸入一次這些基本資料呢。」這類的情況仍然存在尚未解決。

面對這種情況也另外衍生了一個問題，在不同服務中都提供了不同商品的優惠，比起現金折扣，公司可能更希望是回饋點數的方式，引導顧客使用點數在公司的其他服務上，創造雙重銷售的效果，另外在顧客持有點數的情況下，留住回頭客的機會也會大許多。這與 Uber 這類服務時常贈送折價券，來引誘用戶使用他們平台的服務，都能達到類似的效果。

為了達到利用點數創造顧客回流的效果，以現行不共通的資料，每個平台可能都各自擁有自己的點數或是折價券，導致顧客可以應用這些回饋的選擇變少，並局限於取得點數的該平台使用，十分可惜。

要解決這種跨平台登入並整合資料的問題，我們可以透過單點登入來解決，就如同我們可以在各種網站中登入 Google 來讀取我們的個人資料。

單點登入 SSO

圖片來源 - https://www.netfriends.com/blog-posts/leveraging-single-sign-on-sso-to-protect-your-business
單點登入（SSO，全名 Single Sign-On）是一種身份驗證技術，讓使用者只需要進行一次登錄，就能夠在多個系統或應用程式之間無縫切換，而無需每次都重新登入。這不僅簡化了用戶的登入過程，也不必重複註冊多個帳號，單點登入常用的機制也能增強系統的安全性。

常見的 SSO 協議：

OAuth2: 開放授權框架，常用於 API 授權，讓第三方應用能安全地訪問用戶的資料。想像你去一間餐廳用餐，你給服務員一張通行證，他會讓你進入餐廳。同樣地，OAuth2 就像這張“通行證”，讓第三方應用程式可以安全地進入某些服務取得你的資料。例如，當我們用 Google 登錄其他網站時，網站不會直接拿到密碼，而是透過 OAuth2 取得授權來讀取你選擇分享的資料。
OpenID Connect: 基於 OAuth2 的進階版。用餐廳比喻，這不僅讓你進餐廳，還會告訴餐廳服務員你是誰。它不僅授權第三方應用取得你的資料，還確認你的身份。例如，我們用 Google 登入某個應用，應用程式會自動知道你是誰，並讓你直接使用。
SAML： 這就像公司大樓的保全系統，你只需在門口登記一次，進入後你可以自由在各部門之間走動。SAML 主要應用在企業內部系統，它在身份提供者（例如公司的保全系統）和服務提供者（如內部的財務或 HR 系統）之間傳遞身份信息，讓你無需每次進入新系統時再進行身份驗證。

實施 SSO 的解決方案

在現今技術已經相對成熟的時代，許多解決方案已經成為業界標準，我們不再需要從頭開始開發各種協議，尤其在這類資安議題更是企業不可忽視的一環，若在安全中有任何微小疏忽，都可能帶來嚴重的後果。選擇經過市場與時間驗證的成熟應用，不僅能夠加快部署進度，還能減少維護人力，從而降低整體運營成本，也相對安全。

然而，面對市面上眾多的解決方案，如何選出最符合企業需求的應用，並考量每種方案的優劣勢，成為一個關鍵的決策問題。

自行部署 vs. SaaS 服務的考量

對於企業來說，自行部署解決方案能夠讓企業完全掌握服務的運作，並在部署過程中進行高度自定義，更貼合維運架構上的環境與場景。然而，這種方案往往需要更多的技術資源和時間來進行微調與維護。雖然自行部署帶來了更大的控制權，但企業也需要擁有足夠的技術能力來管理與維護這些系統。

另一方面，選擇 SaaS（Software as a Service）服務，則能夠讓企業專注於核心業務，因為這些服務通常已經在雲端架設好，並且提供各種第三方應用的快速整合功能。SaaS 服務雖然方便且需要較少的維護人力，但相對的費用也較高，並且企業對於系統的完整控制權會比較有限，功能上依賴服務提供商。因此，選擇 SaaS 或自行部署，沒有絕對的對錯，全看企業的需求以及資源配置而定。

案例比較：IdentityServer 與 Keycloak

以當時我們在比較 IdentityServer 和 Keycloak 為例，這兩個方案在市場上都有一定的口碑，各自擁有不同的優勢與特色。

IdentityServer：
IdentityServer 是一個半開源的身份驗證和授權框架，特別適合需要高自定義和微調的場景。它基於 .NET 平台，與 Microsoft 相關技術有良好的兼容性，我們還能在官方文件中看到以 IdentityServer 為範例來實現身份驗證服務，對於已經使用 .NET 平台的企業來說是個不錯的選擇。IdentityServer 的彈性很大，並以程式碼實現功能為主，這意味著企業需要擁有較強的技術能力來維護與管理該系統，並且在部署過程中可能需要花費較多的時間與精力，雖說是開源，但在企業需要使用的附加功能等等需要與官方購買許可證。
Keycloak：
Keycloak 是另一個強大的開源身份和訪問管理解決方案，它提供了現成的企業級功能，並且對於企業的部署需求有很好的支持。Keycloak 支持多種協議，如 OAuth2、OpenID Connect 和 SAML，並且有內建的單點登錄（SSO）和社群平台登錄整合功能。與 IdentityServer 相比，Keycloak 的上手難度較低，並且提供了直觀的管理介面。它的彈性較高，但自定義選項可能相對少一些，對於需要快速上線且不需要大量客制化的企業來說，是個理想的選擇。

我們最後偏好將身份驗證服務架設於地端，而不必仰賴其它第三方服務的穩定性，經過許多的討論與嘗試，我們最終選擇可以讓我們高度自定義功能的 IdentityServer，其中一點也是因為公司中的 .NET 人力非常多。

當時在討論使用哪一款解決方案

架構概念

為了在公司內實現員工的身份認證，我們計畫在 Backstage 中引入 SSO 功能。公司架構的不斷發展，Backstage 將會包含不同平台的微服務，這些微服務同樣需要身份驗證功能。此外，公司本身已有許多系統，這使得實施 SSO 成為必要。與上面提到的面對顧客的角度不同，Backstage 要使用的 SSO 版本屬於面對內部員工的。

Backstage 與 Active Directory 同步

在 Backstage 中，使用者登入必須與一個實體對應。若要手動建立數百個使用者實體，這將是一項極為繁瑣的工作。透過 Backstage 與 Active Directory（AD）的同步，我們可以自動從 AD 的員工清單中建立使用者實體，再結合 OIDC（OpenID Connect）協議實現 SSO 架構，通過映射回傳的 mail 屬性自動完成登入。

社群中實作案例的靈感

我們從社群中的其他實作案例中獲得了許多經驗。例如一家外國房地產公司的 IT 團隊，開發了一個能個透過 Ldap 與 AD 直接驗證的插件，來實現 Backstage 的身份驗證。透過直接針對 Backstage 開發的插件，讓他們能夠直接從 AD 驗證使用者身份，省去了額外架設身份服務的功夫。

此外，另一個比較常見的實作方式是透過 Keycloak 部署身份驗證服務，再與 Backstage 進行整合，多數追求能以最小成本完成這件事情，需要快速部署與後續能穩定使用單純需求。

我們的選擇：IdentityServer 與 OTP 系統

針對公司的具體情況，儘管我們考慮了 Keycloak 能快速解決問題的優勢，但最終決定依賴 AD 進行身份驗證，因為現行系統已經大量依賴 AD 作為主要的員工資料來源。使用 AD 進行可以有效利用現有資源，也降低系統整合的複雜性。因此，雖然 Keycloak 提供了 Ldap 串接的選項，但我們決定選擇更符合公司現行架構的方案。

我們選擇使用 IdentityServer，並與公司現有的 OTP 系統進行整合，以加強身份驗證的安全性 (一部分是因為公司政策及現存的系統架構)。通過 IdentityServer，我們可以自行定義身份驗證流程，並進一步擴展 OIDC 驗證流程與 OTP 結合。

文章架構

在接下來的三篇專題文章中，我們將圍繞如何在公司內部實現 SSO，並結合 Backstage 的過程，深入探討每一個重要環節。從公司面臨的實際問題出發，逐步介紹從基礎架構與實作細節的過程。我們將依次探討 AD 的串接、OIDC 的基礎範本，以及 Backstage 插件架構的新舊遷移過程。為了讓讀者更好地理解實作過程，每個文章會稍微補充 AD 和 OIDC 的背景知識。